Valery Smyslov writes:
> > And you can always retry when you notice that you get authentication
> > error after using private key, provided you have multiple types of
> > keys.
> 
> In general you can't if it is responder who selected wrong key. 

That is something I realized on our way home, but it is easy to fix.
We add suggestion to the draft that the responder should use same type
of key than what initiator used.

I.e Initiator selects algorithm based on the CERTREQ and his own
preferences (and one of those might be algorithms already used
previously, or previously tried).

The Responder should select same type of key that was used by
initiator, provided he has the that type of private key. If not, then
he picks a key based on his policy. 

> I admit, that such situations are rare but not non-existent.
> And manual configuration is not an option for large VPNs.

Large VPNs should use centralized management systems anyways, and all
of this is also avoidable by using suitable sub CA keys. You do not
need to change the root CA, it is enough to change the sub CA used to
signing the EE cert, and send CERTREQ containg that key instead.

> Retry is not always possible and is a hack anyway.

For initiator it is possiblity, for responder adding the text which
says it should use same algoritm than other end will solve the issue.

I do not think it as a hack, we already do that in IKEv2 with
Diffie-Hellman group negotiation. On the other hand we do not want to
complicate the IKEv2 more by making the retry inside the exchange like
we do with INVALID_KE_PAYLOAD, but we could add new error notify that
the responder can send which says INVALID_AUTH_KEY_TYPE, and we could
even add supported key types in that notify. Or we can simply use the
AUTHENTICATION_FAILED notify and assume that it might have been
because of wrong key type, and as we do not have anything better to
do, we can simply retry. Nothing will go through the tunnel anyways
unless we do something... 

> There might also be implementations, that supports only md5,
> but we do not consider them, do we?

As I said in draft, MD5 is not considered safe enough to be used in
the signatures. It is OK to use in HMAC etc cases, but not with
signatures. 

> And the problem with the current SIGNATURE_HASH_ALGORITHMS
> is that it decouples hash from signature, assuming that any hash
> could be used with any signature algorithm.

This is feature, not bug as pointed out Johannes Merkle. 

> Actually this is not true, as some algorithms are administratively
> defined only in conjunction with particular hash function. For
> example GOST signature algorithm is defined ONLY with GOST hash.

Which is not problem, as the same policy is in both ends. I.e. if one
end supports GOST it will send GOST hash. If the other end does not
support, it will ignore GOST hash and use some other has (and some
other type of key too). If both ends support GOST hash, and pick GOST
key, they will use GOST hash, as that is only one that is allowed by
their policy.

If one end uses GOST key with any other hash algorithm it is violating
the GOST specification, and it is not expected to work. 

> And even if you could use DSA with SHA-2 or even SHA-3,

You can use DSA with SHA-2. You cannot use it in IKEv2, as the current
DSS signature method is defined to always use SHA-1.

This is one of the reasons we initially started this work. 

> I would more likely expect the existence of crypto
> that supports DSA only with SHA-1, than the crypto,
> that supports only RSA with 1024 bit keys and no other RSA key sizes.

Agree on that, but it is easy to see that some implementations
supporting RSA keys do support SHA-1, some support SHA-1 and SHA-2 and
so on, so the hash negotiation is also needed there. The
implementation which supports both SHA-1 and 2 for RSA cannot use RSA
with SHA-2 unless it knows the other end can support SHA-2.

I agree that my example with 1024-bit RSA support was not good, but
the problem is that there are no good examples of why people would
want to do implementations which only support some features. I.e. it
makes my point stronger that this problem is not seen in real world.
-- 
kivinen@iki.fi